Actually I think you've found a different kind of bug there. You're right that there is an object that's being returned. But the object isn't a Java.util.Date object. I believe that's the function definition for lastModified().

The rule is that if you reference obj.func() then you get the result of the function, but referencing obj.func as a property returns an object of type "function". So I think it's coincidence that allows a String() cast of that function definition to return the right value. The value returned from the lastModified() function is a Long, not a string, and it seems to me to be lucky that it's casting that as a text value for us.

So what do you think about the fix being to ensure that lastModified is always used as a function() rather than as a property? Then the value of lm will be a Long as expected, which might someday be important to other code that someone might add in there.

If you agree, then please withdraw the PR, and I'll get this fix into my version of the code and will close this when it gets merged into a release.

@TonyGravagno thanks for taking a look at this.

I'm not familiar with the Nashorn side of things and how it bridges Java to JavaScript, but the values in that area of the code from the JavaScript context are objects of type java.lang.Long:

// modification at line 167
var lm = dirObject.lastModified();
var dw = dirsWatched[dir];
var dwLm = dirsWatched[dir].lastModified;
console.log(lm.getClass().getName());      // outputs: java.lang.Long
console.log(dwLm.getClass().getName());    // outputs: java.lang.Long

It seems like java.lang.Long isn't correctly translating to a JavaScript number, where the isEquals == comparison would work in that case. But I am likely misunderstanding what you say about:

there is an object that's being returned... I believe that's the function definition for lastModified()

I totally agree it would be better to not have to manually cast it to a string or number - I'll defer to your fix and close this.

Hope this helps. Thanks again for your efforts and sharing ScriptCraft.

Re-opening just to make sure this gets handled.

For the pathologically curious, this bug is the result of a subtle change in Nashorn behaviour introduced in a Java 8 update (see this thread for the gory details: http://mail.openjdk.java.net/pipermail/nashorn-dev/2016-August/006424.html). Nashorn used to map Java long values to JavaScript Number values, which have the expected value semantics. Then they realized this could invisibly lose information (not every long value can be represented in a Number) so now Nashorn converts long values to java.lang.Long objects… with reference semantics, breaking == expectations.

Change also added into v3.2.3.4.